Event prediction using classifier as coarse filter

ABSTRACT

In an aspect, the present application describes a method including: obtaining account data associated with an account; passing at least some of the account data through a non-sufficient funds classifier, the non-sufficient funds classifier being a machine learning classifier configured to classify the account as either likely to have a non-sufficient funds event or unlikely to have a non-sufficient funds event, the machine learning classifier configured to evaluate a plurality of parameters associated with the account data; in response to determining that the account is likely to have a non-sufficient funds event, forecasting a balance for the account, wherein forecasting the balance for the account includes; and providing, to a client device associated with the account, a notification based on a forecasted balance.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/592,966 entitled “EVENT PREDICTION USING CLASSIFIER AS COARSEFILTER”, filed on Oct. 4, 2019, the entire contents of which areincorporated herein by reference.

TECHNICAL FIELD

The present disclosure relates to adaptive notifications for accountsand, more specifically, to systems and methods for predicting futureaccount events based on a past transfers and for providing notificationsbased on such predicted future account events.

BACKGROUND

Transfers between various accounts, such as bank accounts, are ofteninitiated electronically. For example, paychecks may be depositedelectronically by way of direct deposit and bills may be paidelectronically by way of pre-authorized payments or by way of anelectronic payment initiated through an online channel. Since, forexample, third parties may have some control over inflows and outflowsfor a customer account, the convenience provided by such electronictransferring has sometimes left customers with less insight into thestatus of their account. For example, a user receiving payroll through acheque may notice when, for example, a cheque is not received for a payperiod but a user receiving payroll through direct deposit may notimmediately notice a payment that was not received. Some users who donot regularly track inflows and outflows to an account may inadvertentlyfall short of funds. By way of example, such a user may have a chequerejected for non-sufficient funds.

Furthermore, many billers such as utility companies, Internet providers,etc., have eschewed paper-based billing in favor of electronic billing.While this offers an added convenience for some users, others may missbills due to, for example, email fatigue or password fatigue. That is,some bills may go unnoticed because they become overlooked in an emailinbox or because a password is required to access such bills and theuser has difficulty in remembering the password.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments are described in detail below, with reference to thefollowing drawings:

FIG. 1 is a schematic operation diagram illustrating an operatingenvironment of an example embodiment;

FIG. 2 is high-level schematic diagram of an example computing device;

FIG. 3 shows a simplified organization of software components stored ina memory of the example computing device of FIG. 2;

FIG. 4 is a flowchart of an example method in accordance with an exampleembodiment of the present disclosure;

FIG. 5 is a flowchart of an example method in accordance with an exampleembodiment of the present disclosure;

FIGS. 6A and 6B illustrate a flowchart of an example method inaccordance with an example embodiment of the present disclosure;

FIG. 7 is a flowchart of an example method in accordance with an exampleembodiment of the present disclosure; and

FIGS. 8A and 8B are a flowchart of an example method in accordance withan example embodiment of the present disclosure.

Like reference numerals are used in the drawings to denote like elementsand features.

DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS

Described herein are systems and methods which may, for example, providenotifications to client devices associated with an account when aparticular condition associated with the account is detected. Forexample, in at least some implementations, systems and methods foridentifying recurrent transfer patterns are described. Such systems may,for example, be used to identify recurring payments, such as recurringbills, from a transfer listing for a user. By identifying such recurringtransfer patterns, such systems may then accurately utilize theidentified recurring transfer patterns in order to, for example,identify upcoming transfers, identify possible shortfall events, and/orprovide notifications based on such identified conditions.

Conveniently, the systems and methods described herein may perform suchidentification and notification with little user interaction orconfiguration. For example, such systems and methods may effectivelyoperate in the background unbeknownst to the user until a notificationis issued to the user through the client device.

By way of example, in an aspect the present application describes acomputer-implemented method. The method may include: storing a set ofcandidate rules, the set of candidate rules defining payment cycles;identifying, from a transaction history for an account, an actual set oftransfers made to a first recipient; identifying a first referencetransfer from the actual set of transfers; for each of at least aplurality of candidate rules in the set of candidate rules, identifying,based on the first reference transfer, an expected set of transfers forthat candidate rule; identifying one of the candidate rules as a closestrule for the actual set of transfers by: a) evaluating each of theplurality of candidate rules by determining a distance metric betweentransfers in the expected set of transfers for that one of the candidaterules and transfers in the actual set of transfers; and b) selecting oneof the candidate rules as the closest rule based on the distancemetrics. The method may further include: identifying a future expectedtransfer based on the identified one of the candidate rules; andproviding a notification to a client device associated with the accountof the future expected transfer.

In at least some implementations, the method may include: identifying asecond reference transfer from the actual set of transfers, the secondreference transfer different from the first reference transfer; and foreach of at least a plurality of candidate rules in the set of candidaterules, identify, based on the second reference transfer, an alternateexpected set of transfers for that candidate rule. Identifying one ofthe candidate rules as the closest rules for the set of transfers mayfurther include evaluating each of the plurality of candidate rules bydetermining a further distance metric between transfers in the alternateexpected set of transfers for that one of the candidate rules andtransfers in the actual set of transfers. The selection of one of thecandidate rules as the closest rule may be based on the further distancemetrics.

In at least some implementations, each of the transfers in the actualset of transfers may be associated with an actual date. Each of thetransfers in the expected sets of transfers may be associated with anexpected date. The distance metric may be based on a comparison ofactual dates and expected dates.

In at least some implementations the distance metric for a candidaterule may be determined as an average of a difference between respectivedates in the actual set of transfers and the expected set of transfersfor that candidate rule.

In at least some implementations the future expected transfer may beassociated with a date and wherein the notification is provided inresponse to determining that a date of the future expected transfer iswithin a defined proximity of a current date.

In at least some implementations, each of the transfers in the actualset of transfers may be associated with a value and wherein the distancemetrics are determined based on the value.

In at least some implementations, each of the transfers in the actualset of transfers may be associated with an actual value and each of thetransfers in the expected sets of transfers may be associated with anexpected value and the distance metric may be based on a comparison ofactual values and expected values.

In at least some implementations, identifying the future expectedtransfer may include identifying a value associated with the futureexpected transfer and wherein the notification identifies the value.

In at least some implementations, the candidate rules may include one ormore of following rules: transfers are due monthly; transfers are dueweekly; transfers are due yearly; transfers are due monthly but anytransfer falling due on a weekend will, instead, be due a next weekday;transfers are due weekly but any transfer falling due on a weekend will,instead, be due on a next weekday; transfers are due yearly but anytransfer falling due on a weekend will, instead, be due on a nextweekday; transfers are due monthly but any transfer falling due on aweekend or a holiday will, instead, be due a next weekday; transfers aredue weekly but any transfer falling due on a weekend or a holiday will,instead, be due on a next weekday; and transfers are due yearly but anytransfer falling due on a weekend or a holiday will, instead, be due ona next weekday.

In at least some implementations, the notification may indicate aprojected future balance.

In at least some implementations, the method may include sending amessage to the client device requesting confirmation of the identifiedcandidate rule or the future expected transfer.

In at least some implementations, the method may include, after apredetermined period of time has elapsed following the identification ofone of the candidate rules, re-identifying one of the candidate rules asthe closest rule for the actual set of transfers by evaluating eachcandidate rule based on recent transfers. The recent transfers mayinclude at least some transfers occurring after a previousidentification of one of the candidate rules.

Conveniently, such techniques may be used to accurately predict a rulethat defines a recurrent transfer pattern. Such techniques may, forexample, allow pattern-matching to be performed for each account on anindividualized basis. Such individualized pattern matching may, forexample, provide improved accuracy of pattern detection since it allowsthe pattern of transfers for a particular recipient to be different fordifferent accounts. By way of example, some parties may submit amortgage payment weekly whereas others may submit a mortgage paymentmonthly.

In some implementations, techniques described herein may be used when auser begins transfers with a particular counterparty for the first time.For example, in some implementations, a recurrent transfer pattern maybe identified for an account even when the account has little history oftransfers with that counterparty. For example, in at least someimplementations, a pattern may be determined based on a single transferwith a counterparty. In such circumstances, when a new counterparty isdetected for a particular account, the pattern of recurrent transfersfor that counterparty for that account may be initialized based onrecurrent transfer for that counterparty for other accounts (e.g., forother users). By way of example, if a particular cellular phone providertends to be paid monthly (as determined from other user accounts), thenthe recurrent transfer pattern for that provider and that particularaccount may be initialized to be a monthly pattern of transfers. Then,once sufficient data is received for the particular account (e.g., oncea series of transfers have been performed), the recurrent transferpattern may be re-assessed based on data from the particular accountitself.

Conveniently, such techniques may allow notifications to be provided fora user immediately after a first transfer with a particular counterpartyoccurs. That is, there is no need to wait until a sufficient number oftransfers with the counterparty have occurred before beginning toprovide such notifications.

In an aspect, the present application describes a method. The method mayinclude: identifying, from a set of accounts each having a transferlisting that includes a plurality of transfers with a firstcounterparty, a first rule matching a pattern of transfers associatedwith the first counterparty; identifying, for a first account notincluded in the set of accounts, an initial transfer with the firstcounterparty represented in a transfer listing for that account, andwherein the transfer listing for that account does not include a secondtransfer with the first counterparty; identifying one or more projectedfuture transfers for first account based on a date associated with theinitial transfer and the first rule; detecting one or more furthertransfers with the first counterparty from the transfer listing for thefirst account; determining, based on the one or more further transfersand the initial transfer, that a second rule matches a pattern definedby the further transfers and the initial transfers better than the firstrule; and providing a notification to a client device associated withthe first account based on the second rule.

In at least some implementations, providing the notification to theclient device may include: identifying one or more projected futuretransfers for the first account based on the second rule; determining aforecasted balance by adjusting a current balance based on the one ormore projected future transfers; and providing the notification based onthe forecasted balance.

In at least some implementations, the notification may be a notificationof at least one of the projected further transfers.

In at least some implementations, the method may include: prior todetecting the one or more further transfers, providing a notification toa client device associated with the first account based on the firstrule.

In at least some implementations, the first rule and the second rule maybe each one of: transfers are due monthly; transfers are due weekly;transfers are due yearly; transfers are due monthly but any transferfalling due on a weekend will, instead, be due a next weekday; transfersare due weekly but any transfer falling due on a weekend will, instead,be due on a next weekday; transfers are due yearly but any transferfalling due on a weekend will, instead, be due on a next weekday;transfers are due monthly but any transfer falling due on a weekend or aholiday will, instead, be due a next weekday; transfers are due weeklybut any transfer falling due on a weekend or a holiday will, instead, bedue on a next weekday; and transfers are due yearly but any transferfalling due on a weekend or a holiday will, instead, be due on a nextweekday.

In at least some implementations, the method may include sending amessage to the client device requesting confirmation of the second rule.

In at least some implementations, the first account may include a bankaccount.

In at least some implementations, identifying the first rule matching apattern of transfers associated with the first counterparty may beperformed by ranking a plurality of rules in a candidate rule set basedon frequency of use in the set of accounts, and wherein the first ruleis identified as being most frequently used.

In at least some implementations, the method may further include, priorto determining that the second rule matches a pattern defined by thefurther transfers and the initial transfers better than the first rule,identifying the second rule as a second most-frequently used rule in thecandidate rule set based on the ranking and wherein the determining thatthe second rule matches a pattern defined by the further transfers andthe initial transfers better than the first rule is performed inresponse to the identifying of the second rule.

In at least some implementations, detecting one or more furthertransfers with the first counterparty from the transfer listing for thefirst account may include determining that the first account includes atleast a threshold number of transfers with the first counterparty. Thedetermining that the second rule matches a pattern defined by thefurther transfers and the initial transfers better than the first rulemay be performed in response to determining that the first accountincludes at least the threshold number of transfers.

Conveniently, techniques described herein may be used to monitor forpredicted conditions, such as a shortfall in funds, and to notify anaffected user when such conditions are predicted. At least sometechniques described herein are optimized to reduce a computing burdenplaced on a system performing such predictive analysis. For example, onetechnique may save processing resources by using a classifier as acoarse filter. For example, a non-sufficient funds classifier may beused as a course filter to identify accounts that should be furtheranalyzed by performing more computationally-intensive analysistechniques. Such an approach may allow automated monitoring of a largevolume of accounts without overburdening computing system resources.

For example, in an aspect a method of notifying of a predicted conditionis described. The method may include: obtaining account data associatedwith an account; passing at least some of the account data through anon-sufficient funds classifier, the non-sufficient funds classifierincluding a machine learning classifier configured to classify theaccount as either likely to have a non-sufficient funds event orunlikely to have a non-sufficient funds event, the machine learningclassifier configured to evaluate a plurality of parameters associatedwith the account data; in response to determining that the account islikely to have a non-sufficient funds event, forecasting a balance forthe account, wherein forecasting the balance for the account includes:a) identifying one or more projected future transfers for the account byidentifying a pattern of past transfers associated with the account; andb) determining a forecasted balance by adjusting a current balance basedon the one or more projected future transfers; and providing, to aclient device associated with the account, a notification based on theforecasted balance.

In at least some implementations, the method may further include, priorto passing at least some of the account data through the non-sufficientfunds classifier, training the non-sufficient funds classifier based ona training set. The training set may include account data for aplurality of accounts and a non-sufficient funds indication for each ofthe accounts. The non-sufficient funds indication may indicate whetherthe associated account is associated with a non-sufficient funds event.

In at least some implementations, training may include determiningrespective weights for the plurality of parameters.

In at least some implementations, the plurality of parameters mayinclude one or more of: a past non-sufficient funds event; a locationindicator identifying a location; an account duration indicating alength of time since the account was opened; a balance; an indication ofdecrease in income; and an indication of spending in a defined spendingcategory.

In at least some implementations, the notification may be provided inresponse to determining that the forecasted balance is expected to fallbelow a defined threshold.

In at least some implementations, the defined threshold may be zero.

In at least some implementations, the notification may include aselectable option to transfer value from another account.

In at least some implementations, the future transfers may include atleast one incoming transfer and at least one outgoing transfer.

In at least some implementations, the account data may be passed throughthe non-sufficient funds classifier includes a transaction listing.

In at least some implementations, the account data may be passed throughthe non-sufficient funds classifier includes biographical data.

In another aspect, there is described a computing system, such as aserver. The computing system includes a communications module, aprocessor coupled to the communications module and a memory storingprocessor-executable instructions which, when executed, configure theprocessor to perform a method described herein.

In a further aspect, there is provided a non-transitory computerreadable storage medium including processor-executable instructionswhich, when executed, configure a processor to perform a methoddescribed herein.

Other aspects and features of the present application will be understoodby those of ordinary skill in the art from a review of the followingdescription of examples in conjunction with the accompanying figures.

In the present application, the term “and/or” is intended to cover allpossible combinations and sub-combinations of the listed elements,including any one of the listed elements alone, any sub-combination, orall of the elements, and without necessarily excluding additionalelements.

In the present application, the phrase “at least one of . . . or . . . ”is intended to cover any one or more of the listed elements, includingany one of the listed elements alone, any sub-combination, or all of theelements, without necessarily excluding any additional elements, andwithout necessarily requiring all of the elements.

FIG. 1 is a schematic operation diagram illustrating an operatingenvironment of an example embodiment.

As illustrated, a server 160 (which may also be referred to as a servercomputer system or a computing system) and a client device 150communicate via a network 120. The client device 150 is a computingdevice that may be associated with an entity, such as a user, customeror client, having an account associated with the server 160. The accountmay be an account that is used for storing resources or value. In oneparticular example, the account may be a bank account and the server maybe associated with a financial institution such as a bank. For example,the server 160 may track, manage, maintain, and/or lend resources to theentity. The resources may, for example, be computing resources, such asmemory or processor cycles. By way of further example, the resources mayinclude stored value, such as fiat currency, which may be represented ina database. For example, the server 160 may be coupled to a database180, which may be provided in secure storage. The secure storage may beprovided internally within the server 160 or externally. The securestorage may, for example, be provided remotely from the server 160. Forexample, the secure storage may include one or more data centers. Thedata centers may, for example, store data with bank-grade security.

The database 180 may include records for a plurality of accounts and atleast some of the records may define a quantity of resources. Forexample, the entity that is associated with the client device 150 may beassociated with an account having one or more records in the database.The records may reflect a quantity of stored resources that areassociated with the entity and a transfer listing. Such resources mayinclude owned resources and, in at least some embodiments, borrowedresources. The resources that are associated with an entity may begrouped into various buckets. Some such buckets may, for example,represent individual bank accounts. For example, an entity may beassociated with one or more bank accounts.

Accordingly, an account may be associated with a transaction history,which may also be referred to as a transfer history or a transactionhistory herein. The transaction history is a listing of pasttransactions. The transaction history may include both incomingtransactions (i.e., transfers in which the associated account is therecipient of a transfer of value) and outgoing transactions (i.e.,transfers in which another account is the recipient of a transfer ofvalue from the associated account). Each transaction/transfer in thetransaction history is associated with at least a date and a quantum ofvalue. For example, each transfer may define an amount of resourcestransferred and the date on which the transfer occurred. Each transfermay also include one or more identifiers, such as a counterpartyidentifier. The counterparty identifier may, for an incoming transfer,identify a sender and, for an outgoing transfer, identify a recipient.

The entity that is associated with the client device 150 and the accountmay be a customer of a financial institution which operates or managesthe server 160. The financial institution may, for example, offer retailbanking services to the entity.

The client device 150 and the server 160 may be in geographicallydisparate locations. Put differently, the client device 150 may beremote from the server 160.

The client device 150 and the server 160 are computer systems. Theclient device 150 may take a variety of forms including, for example, amobile communication device such as a smartphone, a tablet computer, awearable computer such as a head-mounted display or smartwatch, a laptopor desktop computer, or a computing device of another type.

The client device 150 may communicate with the server 160 via thenetwork 120 in order to manage the use of resources. For example, theclient device 150 may access the server to access a graphical userinterface for viewing account data such as for example, the transactionlisting. As will be described herein, the server 160 may, in at leastsome embodiments, provide notifications to the client device 150.

The network 120 is a computer network. In some embodiments, the network120 may be an internetwork such as may be formed of one or moreinterconnected computer networks. For example, the network 120 may be ormay include an Ethernet network, an asynchronous transfer mode (ATM)network, a wireless network, or the like.

The client device 150 and the server 160 are computing devices.Referring now to FIG. 2, a high-level operation diagram of an examplecomputing device 200 will now be described. The example computing device200 may be exemplary of the client device 150 and/or the server 160.

The example computing device 200 includes a variety of modules. Forexample, as illustrated, the example computing device 200 may include aprocessor 210, a memory 220, a communications module 230, and/or astorage module 240. As illustrated, the foregoing example modules of theexample computing device 200 are in communication over a bus 250.

The processor 210 is a hardware processor. The processor 210 may, forexample, be one or more ARM, Intel x86, PowerPC processors or the like.

The memory 220 allows data to be stored and retrieved. The memory 220may include, for example, random access memory, read-only memory, andpersistent storage. Persistent storage may be, for example, flashmemory, a solid-state drive or the like. Read-only memory and persistentstorage are a non-transitory computer-readable storage medium. Acomputer-readable medium may be organized using a file system such asmay be administered by an operating system governing overall operationof the example computing device 200.

The communications module 230 allows the example computing device 200 tocommunicate with other computing devices and/or various communicationsnetworks. For example, the communications module 230 may allow theexample computing device 200 to send or receive communications signals.Communications signals may be sent or received according to one or moreprotocols or according to one or more standards. For example, thecommunications module 230 may allow the example computing device 200 tocommunicate via a cellular data network, such as for example, accordingto one or more standards such as, for example, Global System for MobileCommunications (GSM), Code Division Multiple Access (CDMA), EvolutionData Optimized (EVDO), Long-term Evolution (LTE) or the like.Additionally or alternatively, the communications module 230 may allowthe example computing device 200 to communicate using near-fieldcommunication (NFC), via Wi-Fi™, using Bluetooth™ or via somecombination of one or more networks or protocols. In some embodiments,all or a portion of the communications module 230 may be integrated intoa component of the example computing device 200. For example, thecommunications module may be integrated into a communications chipset.

The storage module 240 allows the example computing device 200 to storeand retrieve data. In some embodiments, the storage module 240 may beformed as a part of the memory 220 and/or may be used to access all or aportion of the memory 220. Additionally or alternatively, the storagemodule 240 may be used to store and retrieve data from persisted storageother than the persisted storage (if any) accessible via the memory 220.In some embodiments, the storage module 240 may be used to store andretrieve data in a database. A database may be stored in persistedstorage. Additionally or alternatively, the storage module 240 mayaccess data stored remotely such as, for example, as may be accessedusing a local area network (LAN), wide area network (WAN), personal areanetwork (PAN), and/or a storage area network (SAN). In some embodiments,the storage module 240 may access data stored remotely using thecommunications module 230. In some embodiments, the storage module 240may be omitted and its function may be performed by the memory 220and/or by the processor 210 in concert with the communications module230 such as, for example, if data is stored remotely. The storage modulemay also be referred to as a data store.

Where the example computing device 200 functions as the server 160 ofFIG. 1, the storage module 240 may allow the example computing device200 to access the secure data in the database 180.

Software comprising instructions is executed by the processor 210 from acomputer-readable medium. For example, software may be loaded intorandom-access memory from persistent storage of the memory 220.Additionally or alternatively, instructions may be executed by theprocessor 210 directly from read-only memory of the memory 220.

The computing device 200 will include other components apart from thoseillustrated in FIG. 2 and the specific component set may differ based onwhether the computing device 200 is operating as the client device 150or the server 160. For example, the computing device 200 may include oneor more input modules, which may be in communication with the processor210 (e.g., over the bus 250). The input modules may take various formsincluding, for example, a mouse, a microphone, a camera, a touchscreenoverlay, a button, a sensor, etc. By way of further example, thecomputing devices 200 may include one or more output modules, which maybe in communication with the processor 210 (e.g., over the bus 250). Theoutput modules include one or more display modules which may be ofvarious types including, for example, liquid crystal displays (LCD),light emitting diode displays (LED), cathode ray tube (CRT) displays,etc. By way of further example, the output modules may include aspeaker.

Furthermore, the server 160 is a system which may be comprised ofnumerous computing devices that are communicably connected to one other(e.g., over a network).

FIG. 3 depicts a simplified organization of software components storedin the memory 220 of the example computing device 200 (FIG. 2). Asillustrated, these software components include an operating system 300and an application 310.

The operating system 300 is software. The operating system 300 allowsthe application 310 to access the processor 210 (FIG. 2), the memory220, and the communications module 230 of the example computing device200 (FIG. 2). The operating system 300 may be, for example, Google™Android™, Apple™ iOS™, UNIX™, Linux™, Microsoft™ Windows™, Apple OSX™ orthe like.

The application 310 adapts the example computing device 200, incombination with the operating system 300, to operate as a deviceperforming a particular function. For example, the application 310 maycooperate with the operating system 300 to adapt a suitable embodimentof the example computing device 200 to operate as the client device 150,the server 160 and/or the administrator device 170.

While a single application 310 is illustrated in FIG. 3, in operationthe memory 220 may include more than one application 310 and differentapplications 310 may perform different operations.

Operations performed by the client device 150 and the server 160 will bedescribed below. Referring first to FIG. 4, a flowchart showing exampleoperations is illustrated.

FIG. 4 is a flowchart showing operations performed by a server 160. Theoperations may be included in a method 400 which may be performed by theserver 160. For example, computer-executable instructions stored inmemory of the server 160 may, when executed by a processor of the server160, configure the server 160 to perform the method 400 or a portionthereof. For example, such instructions may, when executed by theprocessor of the server 160, configure the processor of the server 160to perform the method.

At operation 402, the server 160 may train a machine learning module,such as a classifier. The classifier is used for mapping input data to aspecific category. In order to do so, the classifier may be configuredto evaluate a plurality of parameters.

In at least some implementations, the classifier may be trained toidentify accounts that are likely to fall short of resources. Suchaccounts may, for example, be referred to as non-sufficient fundsaccounts and a classifier that is configured to identify such accountsmay be referred to as a non-sufficient funds classifier. Falling shortof resources may be said to occur when a shortfall event occurs.Shortfall events may include any one or a combination of: having acheque that was to be drawn from the account returned for non-sufficientfunds, having insufficient resources to pay a bill before a due date,having an account balance that falls below a threshold, which may bezero, having an account balance that falls below a non-zero threshold(such as a minimum threshold required to obtain a perk, such as waiverof an account fee, etc.), having a point-of-sale transaction that was todraw funds from the account denied for lack of funds, and/or having theaccount enter an overdrawn condition. Other conditions may define ashortfall of resources in other implementations. The classifier may beconfigured to identify accounts that are expected to have a shortfallevent. For example, in some implementations, the classifier may beconfigured to identify accounts that are expected to have a shortfallevent within a predetermined period of time (e.g., within the next week,month, etc.).

Training of the classifier may be performed based on a training set. Thetraining set may include historical account data. The training setincludes some accounts that have experienced shortfall events and mayinclude some accounts that have not experienced shortfall events. Thetraining set may, in some instances, be pre-marked with indications of ashortfall event. By way of example, the training set may, for an accountthat experienced a shortfall event, indicate a date of the shortfallevent. In some embodiments, the historical account data may bepreprocessed by the server 160 prior to training the classifier. Duringpre-processing, the server 160 may identify shortfall events. Suchevents may be identified, for example, from the historical account data.For example, the account data may include metadata identifying shortfallevents. For example, a transaction listing may be included in theaccount data and may list past transactions including, for example,transactions that have been denied. For example, point-of-saletransactions that were declined and/or cheques that were returned fornon-sufficient funds may be reflected in the transaction listing. Duringpre-processing, such events may be further flagged for easieridentification by the classifier. By way of further example, shortfallevents that are associated with the balance falling below a definedthreshold may be identified and flagged.

The flagging of shortfall events or the metadata identifying shortfallevents may act as a non-sufficient funds indication which indicateswhether the associated account is associated with a non-sufficient fundsevent.

In at least some implementations, during the pre-processing the server160 may include/exclude certain portions of the transaction listing. Forexample, events that are deemed too old (e.g., more than a thresholdperiod of time before the shortfall event may be excluded).

During pre-processing, the server 160 may also mark events or other datathat correspond to parameters that are used by/considered by theclassifier. For example, the parameters may include one or more of: apast non-sufficient funds event; a location indicator identifying alocation (e.g., a location of an account holder); an account durationindicating a length of time since the account was opened; a balance(e.g., a balance meeting certain defined criteria which may be based ona threshold); an indication of decrease in income; and an indication ofspending in a defined spending category (e.g., the amount of spending onrestaurants in a month).

The classifier may be trained based on the training set at operation402. The training set, which may be the pre-processed training set, mayinclude account data for a plurality of accounts and may include anon-sufficient funds indication for each of the accounts. Thenon-sufficient funds indication indicates whether the associated accountis associated with a non-sufficient funds event. The account data thatis passed through the classifier to train the classifier may includetransaction listings and may also include other biographical dataassociated with the account. For example, the biographical data mayinclude a location associated with the account. The location may be ageographical location and may include one or more of a city, state,province, or country. As noted above, some events/criteria associatedwith the parameters may be marked/flagged during pre-processing and themarked/flagged data may be passed to the classifier during the training.

During the training, the server 160 may determine respective weights fora plurality of parameters. The plurality of parameters may includeparameters such as those recited above. For example, the plurality ofparameters may include one or more of: a past non-sufficient fundsevent; a location indicator identifying a location (e.g., a location ofan account holder); an account duration indicating a length of timesince the account was opened; a balance (e.g., a balance meeting certaindefined criteria which may be based on a threshold); an indication ofdecrease in income; and an indication of spending in a defined spendingcategory (e.g., the amount of spending on restaurants in a month). Otherparameters may be used instead of or in addition to the parametersidentified above. During testing, it has been determined that one of themost-significant indicators of a future shortfall event is a pastshortfall event. Accordingly, a past non-sufficient funds event may be aparameter that is weighted strongly to have a large effect on the outputof the classifier.

The classifier may be of a variety of types. The classifier may besupervised. In other implementations, unsupervised classifiers may beused.

After the classifier has been trained, various variables or weights thatwere determined during the training may be stored. The classifier maythen be used to rapidly classify other accounts (i.e., accounts not partof the training set). For example, at operation 404, the server 160 mayobtain account data that is not included in the training set. That is,the server may, at operation 406, pass at least some of the account datathrough the classifier. The classifier may, as noted above, be anon-sufficient funds classifier, which is a machine learning classifierconfigured to classify the account as either likely to have anon-sufficient funds event or unlikely to have a non-sufficient fundsevent. To perform such classification, the machine learning classifiermay be configured to evaluate a plurality of parameters associated withthe account data and the parameters may be the same parameters used inthe training. For example, the classifier may consider both atransaction listing and biographical data for each account. In at leastsome implementations, prior to passing the account data to theclassifier, the server may pre-process at least some of the accountdata. Pre-processing may be performed in the same manner as thepre-processing of the training data. For example, variousevents/criteria that are associated with the parameters used in theclassifying may be identified. For example, the server may identify suchparameters as: a past non-sufficient funds event; a location indicatoridentifying a location (e.g., a location of an account holder); anaccount duration indicating a length of time since the account wasopened; a balance (e.g., a balance meeting certain defined criteriawhich may be based on a threshold); an indication of decrease in income;and an indication of spending in a defined spending category (e.g., theamount of spending on restaurants in a month).

The classifier may provide a binary output in at least someimplementations. For example, the classifier may have outputs thatinclude either an indication that the account is likely to have anon-sufficient funds event or an indication that the account is notlikely to have a non-sufficient funds event. If the server determinesthat the account is not likely to have a non-sufficient funds event,subsequent operations of the method may not be performed. In particular,the forecasting and notification operations described below may not beperformed in such a scenario. For example, if the server determines thatthe account is not likely to have a non-sufficient funds event, it mayproceed to perform operation 406 again for account data associated withanother account.

If, however, the server 160 determines (at operation 408) that theaccount is likely to have a non-sufficient funds event, then the server160 may further evaluate the account. That is, in response todetermining that the account is likely to have a non-sufficient fundsevent, the server 160 may further evaluate the account by, for example,forecasting a balance for the account (operation 410). For example, theserver may forecast a future balance for the account. In someembodiments, the server may forecast a balance at a date which is atleast a defined period of time in the future. For example, the servermay forecast a balance 1 week in the future or 1 month in the future. Insome implementations, the server may forecast a balance over a range oftime. For example, a balance may be forecasted for each of a pluralitydates within a time period. For example, in some implementations, thebalance may be forecasted for each date within the time period.

In order to forecast a balance for the account, the server may, forexample, identify one or more projected future transfers for the accountby identifying a pattern of past transfers associated with the account.Example techniques for identifying a pattern of past transfers will bediscussed below and, in particular, in the discussion of FIGS. 5 to 8.Such techniques may be used at operation 410 in order to identify apattern of transfers for a particular account and then determine one ormore future transfers based on such pattern. By way of example, for aparticular counterparty that is reflected in the transaction listing foran account, the pattern of transfers may be determined to be monthlytransfers. For such a party, a future transfer may be projected based ona last transfer date for that counterparty. For example, if a lasttransfer occurred on June 10, then it may be expected that the nexttransfer will occur on July 10. Other patterns may be determined forother counterparties and/or for other accounts. By way of example,supported patterns may include one or more of: transfers are duemonthly, transfers are due weekly, transfers are due yearly, transfersare due monthly but any transfer falling due on a weekend will, instead,be due a next weekday, transfers are due weekly but any transfer fallingdue on a weekend will, instead, be due on a next weekday, transfers aredue yearly but any transfer falling due on a weekend will, instead, bedue on a next weekday, transfers are due monthly but any transferfalling due on a weekend or a holiday will, instead, be due a nextweekday, transfers are due weekly but any transfer falling due on aweekend or a holiday will, instead, be due on a next weekday, andtransfers are due yearly but any transfer falling due on a weekend or aholiday will, instead, be due on a next weekday.

Patterns may be identified independently for multiple counterparties andpatterns may be identified for both incoming transfers (e.g., payroll)and outgoing transfers (e.g., bill payments). Upcoming transfers maythen be identified for each counterparty independently.

The server may use the patterns to identify a date of a future transfer(i.e., a projected value date of the transfer). The server may alsodetermine a projected value amount for the projected future transfers.For example, the projected value amount may be determined from a lastvalue amount of a transfer with the associated counterparty. By way ofexample, if the most-recent transfer was for $32.33, then the projectedvalue amount may be determined to be $32.33. In other implementations,the server 160 may consider other transfers instead of or in addition tothe most recent transfer with a counterparty to determine the projectedvalue amount for that counterparty. For example, a predetermined numberof recent transfers may be used and the server may, for example,determine the projected value amount as an average or a weighted averageof the amounts of such recent transfers. Where a weighted average isused, the weightings may be configured to favor more recent transfersover older transfers.

In some implementations, the projected value amount for a particularcounterparty may be determined using a pattern analysis or based on apast transfer that is not a most-recent transfer. By way of example,where the counterparty is a utility, such as a gas company or anelectric company, value amounts may be based on seasonal factors. Fortransfers whose amounts may be expected to be seasonal, the server may,in determining a projected value amount for a given time period (e.g.,such as for a particular month), make the determination based on thevalue amount for the same time period in a previous year, such as a mostrecent year (e.g., such as for the same month last year). In someimplementations, the projected value transfer amount may be determinedas the value amount for the same time period in the previous year. Insome other implementations, the projected value amount may be determinedby applying an inflationary (or, in some instances, deflationary)adjustment to the value amount for the same time period last year. Theamount of inflation (or deflation as the case may be) may be determinedby, for example, comparing the value amounts for recent past timeperiods to the value amounts for corresponding time periods in the prioryear. By way of example, if, on average, recent months tend to be 5%higher than corresponding months in a prior year, then a 5% inflationaryadjustment may be applied to value amount for the same time period lastyear to determine the projected value amount for the current timeperiod.

Once patterns of past transfers are determined and projected futuretransfers are determined for the various counterparties, the server maydetermine a forecasted balance by adjusting a current balance based onthe one or more projected future transfers. For example, the balance maybe adjusted for the inflows (incoming transfers) and outflows (outgoingtransfers) of resources. For example, in some cases the forecastedbalance may be determined by adjusting the current balance to accountfor at least one incoming transfer and at least one outgoing transfer.

In some instances, the server may also consider non-recurring transferswhen forecasting the balance. For example, the server may adjust thebalance based on recent-non recurring spending reflected in thetransaction listing. Non-recurring spending is spending that does notfollow a defined pattern. For example, spending on groceries, gas,restaurants, etc. may be considered to be non-recurring. In at leastsome embodiments, the forecasted balance may be determined based, inpart, on recent non-recurring spending. For example, typical spending invarious categories may be determined and, in some implementations,typical dates associated with such spending may be determined. Forexample, the server may determine that a particular account holder tendsto spend $100 per week on restaurants and that they tend to incur suchcosts on Saturday nights. In such a scenario, the forecasted balance mayassume a $100 weekly charge on Saturday nights.

Conveniently, by using a classified as a coarse filter to identifyaccounts that have traits that suggest that they may soon experience anon-sufficient funds event and by restricting the forecasting describedat operation 410 to accounts that have been flagged as likely toexperience a non-sufficient funds event, the method 400 of FIG. 4 mayoperate to save computer resources such as processing cycles. That is,the described technique may assist in reducing processing resources overan implementation in which the forecasting of operation 410 wereperformed for all accounts since the forecasting of operation 410 can beconsidered a more processing-intensive operation than the classificationof operation 406.

After the server 160 has forecasted the balance, the server 160 mayprovide at operation 412, to a client device associated with theaccount, a notification. The notification may be based on the forecastedbalance.

The notification at operation 412 or in any of the other notificationoperations described herein may be provided, for example, as anelectronic message sent to an electronic messaging address associatedwith the account. In some implementations, the notification may beprovided as a device notification which is associated with an on-deviceapplication (such as a banking application) but which may be displayedas a message outside of the application's user interface. In at leastsome implementations, when the notification is initially displayed itmay not include secure information. For example, it may only indicatethat the user has a message available. In order to view the notificationin greater detail including, for example, in order to view secureinformation, the entity receiving the notification may need toauthenticate with the server.

Authentication to the server may be provided, for example, by anon-device application that is associated with the server, such as abanking application. A user may input authentication credentials intothe application and the server may receive such authenticationcredentials or a representation thereof, from the client device 150 viaa communications module. The authentication credentials may, forexample, include one or more of: a username, a password, a personalidentification number (PIN), biometric data such as a representation ofa fingerprint, or other data that may be used to verify the identity ofan operator of the client device 150. The server 160 identifies anaccount to which the authentication credentials correspond anddetermines that the authentication credentials are valid beforeproviding the detailed notification, which may include secure data. Thesecure data may include, for example, an indication of the futurebalance.

In at least some implementations, the notification is provided inresponse to determining that the forecasted balance is expected to fallbelow a defined threshold. In some implementations, the definedthreshold may be zero. That is, the server may notify the client devicewhen the account is expected to run out of resources and/or to have ashortfall/non-sufficient funds event. The notification may, in itsdetailed form, indicate one or more of: a date when the account isexpected to run out of resources, a current balance, dates of projectedincoming or outgoing transfers, etc.

The notification may, for example, provide a selectable option totransfer value from another account into the account that is expected toexperience the shortfall. A user may, for example, select the selectableoption to configure a transfer and transfer parameters may beprepopulated in response. For example, a recipient account parameterwhich identifies the account that will be receiving the valuetransferred may be pre-configured to be the account that is expected toexperience the shortfall and/or an amount of the transfer may bepre-configured with an amount that exceeds an amount of the shortfall.

The notification may, in at least some implementations, be provided on adate that is determined from the date of a projected future transferthat may be expected to trigger the shortfall event (e.g., cause theforecasted balance to fall below the threshold). For example, thenotification may be provided a predetermined number of days before theprojected future transfer is expected to occur.

Techniques for identifying patterns of recurring transfers will now bediscussed with reference to FIG. 5.

FIG. 5 is a flowchart showing operations performed by a server 160. Theoperations may be included in a method 500 which may be performed by theserver 160. For example, computer-executable instructions stored inmemory of the server 160 may, when executed by a processor of the server160, configure the server 160 to perform the method 500 or a portionthereof. For example, such instructions may, when executed by theprocessor of the server 160, configure the processor of the server 160to perform the method.

At operation 502, the server 160 stores a set of candidate rules. Theset of candidate rules may define payment cycles. By way of example, thecandidate rules may include one or more of following rules: transfersare due monthly; transfers are due weekly; transfers are due yearly;transfers are due monthly but any transfer falling due on a weekendwill, instead, be due a next weekday; transfers are due weekly but anytransfer falling due on a weekend will, instead, be due on a nextweekday; transfers are due yearly but any transfer falling due on aweekend will, instead, be due on a next weekday; transfers are duemonthly but any transfer falling due on a weekend or a holiday will,instead, be due a next weekday; transfers are due weekly but anytransfer falling due on a weekend or a holiday will, instead, be due ona next weekday; and transfers are due yearly but any transfer fallingdue on a weekend or a holiday will, instead, be due on a next weekday.

The candidate rules may be stored in local or remote memory associatedwith the server and the storing of the candidate rules may be includedin the method 500 or performed prior to operation of the method 500.

At operation 504, the server identifies, from a transaction history foran account, an actual set of transfers made to or with a firstrecipient, which may also be referred to as a first counterparty. Thetransaction history may also be referred to as a transaction listing ortransfer listing. The transaction listing is a list of pasttransactions/transfers. The transaction listing may include incoming andoutgoing transactions, for example. In identifying the actual set oftransfers, the server may utilize metadata in the transaction listing.The metadata may, for example, include a counterparty identifier and theidentification may involve compiling a list of all transfers that have acommon counterparty identifier.

At operation 506, the server 160 identifies a first reference transferfrom the set of actual transfers. For example, the server 160 may selectone of the transfers in the actual set of transfers made to or with thefirst recipient as the first reference transfer. In at least someimplementations, the first reference transfer may be identified as anoldest transfer in the set of actual transfers. In otherimplementations, the first reference transfer may be identified as atransfer that is the oldest transfer within a defined time periodmeasured from a current date. Other methods of identifying the firstreference transfer may also be used.

At operation 508, the server 160 may, for each of at least a pluralityof candidate rules in the set of candidate rules, identify, based on thefirst reference transfer, an expected set of transfers for thatcandidate rule. For example, the server 160 may use the first referencetransfer as a starting point and determine subsequent dates on whichtransfers should be made based on the various candidate rules.

Next, at an operation 510, the server 160 may identify one of thecandidate rules as a closest rule for the actual set of transfers. Forexample, the server may evaluate each of the plurality of candidaterules for which the expected set of transfers has been determined. Suchevaluation may be made by determining a distance metric betweentransfers in the expected set of transfers for that one of the candidaterules and transfers in the actual set of transfers. For example, in someimplementations, each of the transfers in the actual set of transfersmay be associated with an actual date and each of the transfers in theexpected sets of transfers may be associated with an expected date andthe distance metric may be based on a comparison of actual dates andexpected dates. For example, the distance metric for a candidate rulemay be determined as an average of the difference between respectivedates in the actual set of transfers and the expected set of transfersfor that candidate rule. For example, beginning with the first date of atransfer in the expected set of transfers, a difference may bedetermined between that date and a corresponding date in the actual setof transfers and a difference may also be determined between eachsubsequent date in the expected set of transfers and each subsequentdate in the actual set of transfers. Based on such distances, thedistance metric may then be determined, for example, as an average ofthe distances.

Accordingly, in at least some implementations, each of the transfers inthe actual set of transfers is associated with an actual date and eachof the transfers in the expected sets of transfers is associated with anexpected date and the distance metric may be based on a comparison ofactual dates and expected dates.

Once the distances metric is determined, the server 160 may select oneof the candidate rules as the closest rule based on the distancemetrics. For example, the server 160 may attempt to minimize thedistance metric by selecting the candidate rule having the smallestdistance metric.

In some implementations, value of transfers may be considered instead ofor in addition to date. For example, in at least some implementations,each of the transfers in the actual set of transfers may be associatedwith a value and each of the transfers in the expected set of transfersmay be associated with a value and the distance metric may be determinedbased on the value. The value may be an amount or quantity of resourcesand the value may be expressed, for example, in units of currency, suchas dollars, pounds, Euros, etc.

Where the distance metric is configured to consider value, thedifference between a value represented in transfer in the expected setof transfers for a candidate rule and the value represented in acorresponding transfer in the actual set of transfers for the candidaterule may be considered in order to determine the distance metric. Insuch implementations, a candidate rule may be selected which minimizessuch a distance metric. That is, a candidate rule that accuratelypredicts values may be selected. Where both value and date areconsidered, a candidate rule may be selected to jointly minimize avalue-based distance metric and a date-based distance metric. Respectiveweightings for these distance metrics may be predefined so as to controlthe relative significance of each of these distance metrics. In at leastsome implementations, root mean square error minimization may beperformed in order to select the appropriate candidate rule.

At an operation 512, the server 160 is configured to identify a futureexpected transfer based on the identified one of the candidate rules.That is, once a candidate rule which fits the pattern of transfers witha counterparty is identified, that candidate rule may be used toidentify future expected transfers with that same counterparty. Forexample, a next expected transfer may be determined based on, forexample, a most recent one of the transfers in the set of actualtransfers. For example, if the rule indicates that transfers are tooccur monthly and the most-recent transfer occurred on June 11, then theserver 160 may determine that a transfer will occur on July 11.

In some implementations, the server 160 may identify a value associatedwith the future expected transfer. For example, the server 160 mayidentify an amount of resources that is expected to be transferred inthe future expected transfer. The value may be identified based on, forexample, the identified candidate rule and a value of at least one ofthe transfers in the actual set of transfers. For example, in at leastsome implementations, the most recent transfer in the actual set oftransfers may be used.

Next, at an operation 514, the server 160 provides a notification to aclient device associated with the account of the future expectedtransfer. For example, the server may notify the client deviceassociated with an account prior to the future expected transfer. Thenotification may, for example, identify a value associated with anupcoming transfer and/or a date associated with an upcoming transfer.That is, identifying a future expected transfer may include identifyinga value associated with the future expected transfer and thenotification may identify the value. For example, the server 160 mayprovide a message to the client device indicating that a transfer of$32.45 appears to be required by July 11.

In at least some implementations, the notification may indicate aprojected future balance. For example, based on the identified candidaterule, forecasting may be performed. The forecasting may be performed,for example, in the manner described above with reference to operation410 of the method 400. For example, a current balance may be adjusted toaccount for projected future transfers and the projected futuretransfers may be determined by identifying candidate rules using thetechniques of FIG. 5, for example. By way of example, a balance may beforecasted for a predetermined period of time in the future such as, forexample, one month from the current date.

The notification may, in at least some implementations, be provided ator near a date associated with the future expected transfer. Forexample, the future expected transfers may be associated with a date andthe notification may be provided in response to determining that thedate of the future expected transfer is within a defined proximity ofthe current date or, put differently, in response to determining thatthe current date is within a predetermined proximity of the date of thefuture expected transfer. The predetermined proximity may, for example,be defined in terms of a number of days or a number of business days.

The notification provided at operation 514 may, for example, include aselectable option to initiate a transfer. For example, the notificationmay include a selectable link to, for example, transfer value to thefirst recipient. In at least some implementations, selection of theselectable option (using an input interface of the client device) maycause the transfer parameters associated with a transfer to bepre-populated. For example, a recipient identifier may be prepopulatedto identify the first recipient. By way of further example, a dateassociated with the transfer may be configured with a date that is on,or within a predetermined period of time, of a date associated with thefuture expected transfer. By way of further example, a value associatedwith the transfer, which defines an amount of resources beingtransferred, may be pre-populated based on the value associated with thefuture expected transfer.

As described above with reference to FIG. 4, the notification may beprovided in parts. For example, a notification may initially excludesecure data and the secure data may only be provided after the recipientof the notification has authenticated with the server 160.

The techniques described with reference to the method of FIG. 5 ofidentifying a pattern/candidate rule may also be used in other methodsdescribed herein such as, for example, the method 400 of FIG. 4 and, inparticular, operation 410 of the method 400.

Reference will now be made to FIGS. 6A and 6B which illustrate a method600.

FIGS. 6A and 6B are flowcharts showing operations performed by a server160. The operations may be included in a method 600 which may beperformed by the server 160. For example, computer-executableinstructions stored in memory of the server 160 may, when executed by aprocessor of the server 160, configure the server 160 to perform themethod 600 or a portion thereof. For example, such instructions may,when executed by the processor of the server 160, configure theprocessor of the server 160 to perform the method 600.

The method 600 includes many operations previously described above withreference to the method 500 of FIG. 5 and the description of suchoperations will not be repeated in full but will, instead, by made withreference to corresponding operations of FIG. 5. For example, atoperation 602, the server 160 may store a set of candidate rules.Operation 602 may be performed as described above with reference tooperation 502 of the method 500 of FIG. 5.

At operation 604, the server 160 may identify, from a transactionhistory for an account, an actual set of transfers made to a firstrecipient. Operation 604 may be performed as described above withreference to operation 504 of the method 500 of FIG. 5.

At operation 606, the server 160 may identify a first reference transferfrom the actual set of transfers. Operation 606 may be performed in themanner described above with reference to operation 506 of the method 500of FIG. 5.

At operation 608, the method may include, for each of at least aplurality of candidate rules in the set of candidate rules, identifying,based on the first reference transfer, an expected set of transfers forthat candidate rule. Operation 608 may be performed in the mannerdescribed above with reference to operation 508 of the method 500 ofFIG. 5.

Next, at an operation 610, the method may include, identifying a secondreference transfer from the actual set of transfers. The secondreference transfer may be different from the first reference transfer.For example, it may be that the expected set of transfers that wasdetermined based on the candidate rule and the first reference transferdid not well align with the actual set of transfers because the firstreference transfer was a poorly selected reference transfer. In order toaddress this possibility, a second reference transfer may also beselected at operation 610 and, at operation 612, the server 160 may, foreach of at least a plurality of candidate rules in the set of candidaterules, identify, based on the second reference transfer, an alternateexpected set of transfers for that candidate rule. That is, thealternate expected set of transfers may be determined using the secondreference transfer as a starting point.

Next, at an operation 614, the method 600 may include identifying one ofthe candidate rules as a closest rule for the actual set of transfers.Operation 614 may be performed in the manner described above withreference to operation 510 except that identifying one of the candidaterules as the closest rules for the set of transfers may further includeevaluating each of the plurality of candidate rules by determining afurther distance metric between transfers in the alternate expected setof transfers for that one of the candidate rules and transfers in theactual set of transfers and the selection of one of the candidate rulesas the closest rule may be further based on the further distancemetrics. Put differently, each of the candidate rules is evaluated usingdifferent reference dates as a starting point.

In some implementations, the server 160 may request confirmation from aclient device associated with an account of a candidate rule beforeusing that candidate rule. Accordingly, the server 160 may, at operation616, send a message to the client device requesting confirmation of theidentified candidate rule or the future expected transfer. The servermay receive back a message confirming the candidate rule beforeproceeding to an operation 618.

At the operation 618, the server identifies a future expected transferbased on the identified one of the candidate rules. Operation 618 may beperformed in the manner described above with reference to operation 512of the method 500 of FIG. 5.

In some implementations, the server 160 may request confirmation from aclient device associated with an account of the future expectedtransfer. For example, the server may, at operation 620, send a messageto the client device requesting confirmation of the future expectedtransfer. For example, the message may request the client device toconfirm a date and/or a value associated with the future expectedtransfer.

Operation 620 may be performed, for example, as an alternative tooperation 616. The server may receive back a message confirming thefuture expected transfer before proceeding to an operation 622. If,instead, the server receives back a message indicating that the value ordate of the future expected transfer is different, then the server mayattempt to determine if a different candidate rule be better suited.

At operation 622, the server 160 may provide a notification to a clientdevice associated with the account of the future expected transfer.Operation 622 may be performed in the manner described above withreference to operation 514 of the method 500 of FIG. 5.

Next, at an operation 624, the method 600 may include, after apredetermined period of time has elapsed following the identification ofone of the candidate rules, re-identifying one of the candidate rules asthe closest rule for the actual set of transfers by evaluating eachcandidate rule based on recent transfers. The recent transfers includeat least some transfers occurring after a previous identification of oneof the candidate rules. That is, after more transfers have occurred withthe first recipient, the set of candidate rules may, again, bere-evaluated to ensure that the selected candidate rule is still a bestfit for the transaction listing which now includes additional transfers.

In some instances, a transaction listing for an account may not includea sufficient number of transfers with a particular counterparty toidentify a pattern of transfers for that counterparty. For example, whena customer changes cellular service providers, a first transfer with thenew provider may be reflected in the transaction listing but the singletransfer may not, in itself, allow for pattern identification. Referringnow to FIG. 7, a flowchart shows example operations which may, forexample, provide pattern identification in scenarios where an accounthas a short transfer history with a counterparty.

FIG. 7 is a flowchart showing operations performed by a server 160. Theoperations may be included in a method 700 which may be performed by theserver 160. For example, computer-executable instructions stored inmemory of the server 160 may, when executed by a processor of the server160, configure the server 160 to perform the method 700 or a portionthereof. For example, such instructions may, when executed by theprocessor of the server 160, configure the processor of the server 160to perform the method 700.

At operation 702, the method 700 may include identifying, from a set ofaccounts each having a transfer listing (which, may also be referred toherein as a transaction listing) that includes a plurality of transferswith a first counterparty, a first rule matching a pattern of transfersassociated with the first counterparty. The set of accounts may includeaccount data for a plurality of bank accounts which include transferswith a particular counterparty, “the first counterparty”. The transfersmay be or include incoming transfers, such as, for example, a receipt ofvalue associated with payroll processing, and/or may include outgoingtransfers such as, for example, an external transfer made to, forexample, pay a bill.

The server 160 may, as described above with reference to operations 502and 602 of FIGS. 5 and 6, store a set of candidate rules that definepayment cycles. Such rules may include, for example, at least the firstrule and a second rule. The first rule is a rule that best matches thepattern of transfers with the counterparty across all of the accounts inthe set of accounts. For example, the server 160 may perform, for eachaccount in the set of accounts, the operations 504 to operation 510 ofthe method 500 and/or 604 to 614 of the method 600 and the firstcounterparty will act as the “first recipient” as described above forsuch operations in order to identify the closest candidate rule withrespect to each account. Then, the candidate rule that was identified asthe closest rule for the most accounts in the set of accounts may beselected as the “first rule” in operation 702. That is, the first ruleis the rule that is most frequently used for the first counterpartyacross the set of accounts.

Various candidate rules may be included in the set of candidate rulesfrom which the first rule is identified. For example, the rules mayinclude one or more of: transfers are due monthly; transfers are dueweekly; transfers are due yearly; transfers are due monthly but anytransfer falling due on a weekend will, instead, be due a next weekday;transfers are due weekly but any transfer falling due on a weekend will,instead, be due on a next weekday; transfers are due yearly but anytransfer falling due on a weekend will, instead, be due on a nextweekday; transfers are due monthly but any transfer falling due on aweekend or a holiday will, instead, be due a next weekday; transfers aredue weekly but any transfer falling due on a weekend or a holiday will,instead, be due on a next weekday; and transfers are due yearly but anytransfer falling due on a weekend or a holiday will, instead, be due ona next weekday.

The set of accounts that are used to identify the first rule mayrepresent account data for a plurality of actual customers. For example,the account may be a bank account and the customers may be customers ofthe bank. For a given counterparty, it may be expected that the manyaccounts will follow a common transfer schedule. For example, transfersrepresenting a payment due to a particular cellular service provider maybe due, for example, monthly and that cellular service provider may havea policy that any transfer falling due on a weekend will, instead, bedue on a next weekday. Accordingly, by identifying the most commontransfer schedule for the first counterparty, this transfer schedule(i.e., the transfer schedule defined by such a rule) may be used fornotification generation for another account that is not in the set whensuch an account has not yet built up a sufficient transfer history withthe first counterparty for accurate prediction of the payment schedulefrom that other account alone.

At operation 704, the server 160 may identify, for a first account notincluded in the set of accounts, an initial transfer with the firstcounterparty represented in a transfer listing for that account. Thetransfer listing for that account may not have a sufficient number oftransfers with the first counterparty to accurately predict the transferschedule for the transfer listing alone. For example, the transferlisting for that account may not include a second transfer with thefirst counterparty.

Since the first account does not include a sufficient transfer historywith the first counterparty to predict the transfer schedule that isused by the first counterparty, the server 160 may use the first rule(i.e., the rule identified from other accounts at operation 702 for thefirst counterparty) for predictions involving the first counterparty andthe first account. For example, at operation 706, the method 700 mayinclude identifying one or more projected future transfers for the firstaccount based on a date associated with the initial transfer and thefirst rule. For example, the date may be the date of the initialtransfer with the first counterparty represented in the transfer listingfor the first account. Using the first rule, the server 160 may thenpredict when a next transfer is due and/or expected to occur. Forexample, if the rule indicates that the transfers are to occur monthly,then the server may select a date which is one month from the date ofthe initial transfer.

In at least some implementations, the server 160 may determine aprojected value amount for the projected future transfer(s). Forexample, the server 160 may, in at least some implementations, determinethe projected value amount as the value amount for the initial transfer.That is, the server 160 may assume that whatever amount was transferredduring the initial transfer will be approximately the same as whateveramount will be required to be transferred for the projected futuretransfer. Other techniques for determining the projected value amountmay also be used. For example, in some implementations, the server 160may perform some pattern-based analysis such as, for example, usingtechniques described above with reference to, for example, operation 410of the method 400 of FIG. 4. Such pattern matching may be performedbased on, for example, the accounts in the set of accounts.

In at least some implementations, the server 160 may, at operation 708,provide a notification to a client device associated with the firstaccount based on the first rule.

The notification may be provided, for example, as an electronic messagesent to an electronic messaging address associated with the firstaccount. In some implementations, the notification may be provided as adevice notification which is associated with an on-device application(such as a banking application) but which may be displayed as a messageoutside of the application's user interface. In at least someimplementations, when the notification is initially displayed it may notinclude secure information. For example, it may only indicate that theuser has a message available. In order to view the notification ingreater detail including, for example, in order to view secureinformation, the entity receiving the notification may need toauthenticate with the server.

Authentication to the server may be provided, for example, by anon-device application that is associated with the server, such as abanking application. A user may input authentication credentials intothe application and the server may receive such authenticationcredentials or a representation thereof, from the client device 150 viaa communications module. The authentication credentials may, forexample, include one or more of: a username, a password, a personalidentification number (PIN), biometric data such as a representation ofa fingerprint, or other data that may be used to verify the identity ofan operator of the client device 150. The server 160 identifies anaccount to which the authentication credentials correspond anddetermines that the authentication credentials are valid beforeproviding the detailed notification, which may include secure data. Thesecure data may include, for example, an indication of the futurebalance.

The notification may take various forms. For example, the notificationmay, in some implementations, be a notification that is based on aforecasted balance. For example, the server may forecast a balance asdescribed above with reference to operation 410 of the method 400. Theforecasting may be based on, for example, the one or more projectedfuture transfers for the first account that were identified at operation706.

In at least some implementations, the notification is provided inresponse to determining that the forecasted balance is expected to fallbelow a defined threshold. In some implementations, the definedthreshold may be zero. That is, the server may notify the client devicewhen the account is expected to run out of resources and/or to have ashortfall/non-sufficient funds event. The notification may, in itsdetailed form, indicate one or more of: a date when the account isexpected to run out of resources, a current balance, dates of projectedincoming or outgoing transfers, etc.

The notification may, for example, provide a selectable option totransfer value from another account into the account that is expected toexperience the shortfall. A user may, for example, select the selectableoption to configure a transfer and transfer parameters may beprepopulated. For example, a recipient account parameter whichidentifies the account that will be receiving the value transferred maybe pre-configured to be the account that is expected to experience theshortfall and/or an amount of the transfer may be pre-configured with anamount that exceeds an amount of the shortfall.

The notification may, in at least some implementations, be provided on adate that is determined from the date of a projected future transferthat may be expected to trigger the shortfall event (e.g., cause theforecasted balance to fall below the threshold). For example, thenotification may be provided a predetermined number of days before theprojected future transfer is expected to occur.

The notification may take other forms. For example, the notification maybe a notification of an upcoming transfer such as, for example, anotification indicating that a transfer to the first counterparty is duesoon. Such a notification may serve as a reminder to the customer toensure that they configure a transfer to the first counterparty prior toa payment due date. The notification may, for example, include aselectable option to initiate a transfer. For example, the notificationmay include a selectable link to, for example, transfer value to thefirst recipient. In at least some implementations, selection of theselectable option (using an input interface of the client device) maycause the transfer parameters associated with a transfer to bepre-populated. For example, a recipient identifier may be prepopulatedto identify the first recipient. By way of further example, a dateassociated with the transfer may be configured with a date that is on,or within a predetermined period of time, of a date associated with theprojected future transfer. By way of further example, a value associatedwith the transfer, which defines an amount of resources beingtransferred, may be pre-populated based on the value associated with theprojected future transfer.

Next, at an operation 710, the server may detect one or more furthertransfers with the first counterparty from the transfer listing for thefirst account. Detecting one or more further transfers with the firstcounterparty from the transfer listing for the first account may includedetermining that the first account includes at least a threshold numberof transfers with the first counterparty. The threshold may be athreshold which is sufficient to determine a pattern. For example, in animplementation the threshold may be four though other thresholds may beused.

In at least some implementations, in order for the server 160 todetermine that the first account includes a sufficient number oftransfers to determine a pattern, the server 160 may only include recenttransfers; for example, transfers within a threshold period of time ofthe current date.

After the server 160 determines that the first account has a sufficientnumber of transfers with the first counterparty, the server may, atoperation 712, identify a second rule that matches a pattern of paymentcycles represented in the transfer listing for the first account. Thatis, the transfers with the counterparty in the first account itself maynow be used to determine which of the rules, in the set of candidaterules, best matches the pattern of transfers. The determination of thesecond rule may be made based on the further transfers with the firstcounterparty (i.e., the transfers identified at operation 710) and theinitial transfer with the first counterparty (i.e., the transferidentified at operation 704). For example, the server 160 may determine,based on the one or more further transfers and the initial transfer thata second rule matches a pattern defined by the further transfers and theinitial transfers better than the first rule.

The candidate rules that are used at operation 712 to select the secondrule may be the same set of candidate rules that are used at operation702 to select the first rule and the techniques for matching may be asdescribed above. For example, operations 504 to 510 of the method 500 ofFIG. 5 and/or operations 604 to 614 of the method 600 of FIG. 6 may beperformed based on account data for the first account in order toidentify the closest candidate rule.

In some implementations, operation 712 is performed in response todetermining that the first account includes at least the thresholdnumber of transfers. For example, once the threshold number of transferswith the counterparty that is sufficient to determine a pattern isreached, operation 712 may be performed to determine that the secondrule matches a pattern defined by the further transfers and the initialtransfers better than the first rule.

Operation 712 illustrates a scenario in which the server determines thatthe second rule is better than the first rule. In other instances, itmay be that the server, after identifying a rule based on the transferswith the first counterparty in the first account, determines that thefirst rule remains the closest rule. In such circumstances, operation712 may include, for example, verifying, based on the one or morefurther transfers and the initial transfer that the first rule is aclosest rule for the first account.

After a rule has been selected based on the actual transfers for thefirst account (i.e., after operation 712 has been performed), subsequentnotifications that are based on projected future transfers with thefirst counterparty may be based on the rule identified at operation 712as the best rule. For example, if the server 160, at operation 712,determines that a second rule is better than the first rule, thennotifications that are based on projected future transfers with thefirst counterparty may be based on the second rule. Accordingly, atoperation 714, the server 160 may provide a notification to a clientdevice associated with the first account based on the second rule.

The notification may be of a type described above with reference tooperation 708. For example, the notification may be a notification of anupcoming projected future transfer, of a balance, of a projectedshortfall, etc.

The notification may be provided in a manner described above withreference to operation 708.

In some implementations, in providing the notification, the server 160may identify one or more projected future transfers for the firstaccount based on the second rule. Such identification may be performedin the manner described above with reference to operation 706 and/or asdescribed above with reference to operation 512 of the method 500. Forexample, a most recent one of the further transfers may be used as areference date and a date of a projected future transfer may bedetermined based on the second rule and the reference date.

In some implementations, the server 160 may, at operation 714, determinea forecasted balance. The forecasted balance may be determined, forexample, as described above with reference to operation 410 of themethod 400. For example, the forecasted based may be determined byadjusting a current balance based on the one or more projected futuretransfers. Then, in at least some implementations, the server mayprovide the notification based on the forecasted balance. For example,the the notification may a notification of the projected futuretransfer(s) and/or of the forecasted balance.

The method 700 may be varied. By way of example, in some variations ofthe method 700, operation 702 may be performed after operation 704. Forexample, when a transfer with the first counterparty is identified inthe transfer listing for the first account (at operation 704), theserver 160 may then identify other accounts that are to be included inthe set of accounts used for identifying the first rule matching thepattern of transfers. For example, the server 160 may identify aplurality of accounts that each include at least a threshold number oftransfers made with the first counterparty. In at least someimplementations, the server 160 may identify a plurality of accountsthat each include at least a threshold number of transfers made with thefirst counterparty during a threshold period of time. For example, theserver 160 may identify accounts that each have at least three (3)transfers with the first counterparty during a three (3) month period oftime. In some implementations, the server may attempt to identify atleast a threshold number of accounts (e.g., 1000 accounts). In at leastsome implementations, the accounts that are identified for inclusionwithin the first set of accounts are identified based on some othercriteria. For example, in at least some implementations, the accounts inthe set of accounts are identified based on a location. For example,accounts that are in a geographic region that is associated with thefirst account may be identified. By way of example, the accounts may beselected so as to be in the same city, province, state and/or country asthe first account since transfer schedules may be, in some instances,based on local norms.

Reference will now be made to FIGS. 8A and 8B which illustrate, inflowchart form, a further method 800 that is a variation of the method700. The method 800 may be used to improve the speed at which the server160 is able to identify the second rule and/or to reduce processingcycles involved in identifying the second rule.

The method 800 includes many operations in common with the method 700 ofFIG. 7. Description of these operations will not be repeated at lengthand will instead be made through reference to corresponding operationsof the method 700 of FIG. 7. The method 800 incudes, for example, atoperation 802, identifying, from a set of accounts each having atransfer listing that includes a plurality of transfers with a firstcounterparty, a first rule matching a pattern of transfers associatedwith the first counterparty. Operation 802 may be performed, forexample, in a manner that is substantially similar to operation 702 ofthe method 700 of FIG. 7. However, the server 160, in performingoperation 802, rank a plurality of rules in a candidate rule set basedon frequency of use in the set of accounts. For example, the server mayrank all candidate rules based on frequency of use or may, for example,rank only a top threshold number of candidate rules. The first rule maybe a most-frequently used rule and a second rule may be a second-mostfrequently used rule.

Accordingly, rather than simply selecting the top rule, the server mayevaluate how common other rules are and record data (which may bereferred to as ranking data) indicating frequency of use.

Next, operations 804 to 810 may be performed as described above withreference to operation 704 to 710 of the method 700 of FIG. 7respectively.

Next, at an operation 812, the server 160 may, prior to prior todetermining (at operation 814) that the second rule matches a patterndefined by the further transfers and the initial transfers better thanthe first rule, identify the second rule as a second most-frequentlyused rule in the candidate rule set based on the ranking. That is, theserver may retrieve the ranking data. Then, at operation 814, theranking data may be used. For example, the server may evaluate candidaterules one by one in the order of the ranking and, in at least someimplementations, may only evaluate a candidate rules with a sufficientlyhigh rank. For example, candidate rules having a frequency of use ofzero (i.e., rules that appear to never have been used for acounterparty) may not be used.

The operation 814 may be performed in the manner described above withreference to operation 812 but it may, for example, be performed inresponse to the identifying of the second rule at operation 812. Forexample, the server may determine a distance metric for the first rulebased on the account data for the first account and may then (atoperation 812) determine that the second rule is the second mostfrequently used rule based on the ranking data and so the server maythen determine the distance metric for the second rule based on theaccount data for the first account. If the second rule has a betterdistance metric than the first rule, the second rule will be selected.

In some implementations, the server 160 may request confirmation of thesecond rule. For example, at operation 816, the server may send amessage to the client device requesting confirmation of the second rule.The message may, for example, identifying the second rule and identifythe first counterparty. Next, at an operation 818, the server 160receives, via a communication subsystem, a confirmation of the secondrule. After receiving such confirmation, the server may use the secondrule.

The message may also include a selectable option to select a differentone of the candidate rules for the counterparty. In response toreceiving such a selection, the server may begin to use the selecteddifferent one of the candidate rules.

Next, at operation 820, a notification is provided to the client deviceas described above with reference to the operation 714 of the method 700of FIG. 7.

The methods 700 and 800 may be capable of variation. For example,operations 816 and 818 may be performed without, for example, theranking features of the method 800 or, alternatively, the rankingfeatures of the method 800 may be performed without, for example, theconfirmation aspects of operations 8167 and 818.

Furthermore, in at least some implementations, during operation 802 (oroperation 702 as the case may be), the server 160 may, based on theranking, determine a subset of candidate rules. The subset of candidaterules may exclude candidate rules that are infrequently used.Infrequency may be determined based on a threshold which may, forexample be based on a frequency threshold (e.g., a candidate rule musthave been used at least once) or based on a relative rank with respectto other candidate rules (e.g., a candidate rule must have a rank thatis at least in the top five for all candidate rules to be included). Inat least some such implementations, when a second rule is determined atoperation 814 or 712 as the case may be, the determination may be basedon the subset of candidate rules. For example, only the candidate rulesin the subset of candidate rules may evaluated. Put differently, atleast one candidate rule that is in the set of candidate rules used atoperations 802/702 but that is excluded from the subset of candidaterules determined at operations 802/702 is not evaluated. In suchimplementations, during operations 814/712, the server 160 attempts toidentify the closest one of the candidate rules in the subset based onthe account data for the first account (such as the initial and furthertransfers with the counterparty).

Variations of the embodiments described herein are possible. Forexample, while many of the notifications described herein may have beendescribed as displayed notifications (i.e., notifications that areconfigured for display via a display module), in other implementationsthe notifications may be configured for output on an output module ofanother type. For example, in some implementations, the audiblenotifications may be used. By way of example, in one implementation, theclient device 150 may be a smart speaker and the notification may beprovided audibly via a speaker.

Example embodiments of the present application are not limited to anyparticular operating system, system architecture, mobile devicearchitecture, server architecture, or computer programming language.

It will be understood that the applications, modules, routines,processes, threads, or other software components implementing thedescribed method/process may be realized using standard computerprogramming techniques and languages. The present application is notlimited to particular processors, computer languages, computerprogramming conventions, data structures, or other such implementationdetails. Those skilled in the art will recognize that the describedprocesses may be implemented as a part of computer-executable codestored in volatile or non-volatile memory, as part of anapplication-specific integrated chip (ASIC), etc.

As noted, certain adaptations and modifications of the describedembodiments can be made. Therefore, the above discussed embodiments areconsidered to be illustrative and not restrictive.

What is claimed is:
 1. A computing system comprising: a communicationsmodule; a processor coupled to the communications module; and a memorystoring processor-executable instructions which, when executed,configure the processor to: pass account data through a non-sufficientfunds classifier, the non-sufficient funds classifier being a machinelearning binary classifier that is configured to classify an accountassociated with the account data as either likely to have anon-sufficient funds event or unlikely to have the non-sufficient fundsevent, based on an evaluation of a plurality of parameters associatedwith the account data; receive a binary output from the machine learningbinary classifier indicating that the account is likely to have thenon-sufficient funds event; in response to receiving the binary outputindicating that the account is likely to have the non-sufficient fundsevent, performing an evaluation operation on the account data; provide,to a client device associated with the account, a notification based onthe evaluation operation, the notification including a selectable optionto transfer value from another account; receive a request to transfervalue from the another account; and transfer value from the anotheraccount into the account associated with the account data.
 2. Thecomputing system of claim 1, wherein the instructions further configurethe computing system to train the non-sufficient funds classifier basedon a training set by determining respective weights for the plurality ofparameters.
 3. The computing system of claim 2, wherein the plurality ofparameters include one or more of: a past non-sufficient funds event; abalance; and an indication of decrease in income.
 4. The computingsystem of claim 1, wherein the notification is provided in response todetermining, while performing the evaluation operation, that aforecasted balance is expected to fall below a defined threshold.
 5. Thecomputing system of claim 4, wherein the defined threshold is zero. 6.The computing system of claim 1, wherein performing an evaluationoperation on the account data includes determining one or more projectedfuture transfers, and wherein the one or more projected future transfersinclude at least one incoming transfer and at least one outgoingtransfer.
 7. The computing system of claim 1, wherein the account datapassed through the machine learning binary classifier includes atransaction listing.
 8. The computing system of claim 1, wherein theaccount data passed through the machine learning binary classifierincludes biographical data.
 9. The computing system of claim 1, whereinthe evaluation operation performed in response to receiving the binaryoutput indicating that the account is likely to have the non-sufficientfunds event is not performed when a binary output is received indicatingthat the account is not likely to have the non-sufficient funds event.10. A method of notifying of a predicted condition, the methodcomprising: passing account data through a non-sufficient fundsclassifier, the non-sufficient funds classifier being a machine learningbinary classifier that is configured to classify an account associatedwith the account data as either likely to have a non-sufficient fundsevent or unlikely to have the non-sufficient funds event, based on anevaluation of a plurality of parameters associated with the accountdata; receiving a binary output from the machine learning binaryclassifier, the binary output indicating that the account is likely tohave the non-sufficient funds event; in response to receiving the binaryoutput indicating that the account is likely to have the non-sufficientfunds event, performing an evaluation operation on the account data;providing, to a client device associated with the account, anotification based on the evaluation operation, the notificationincluding a selectable option to transfer value from another account;receiving a request to transfer value from the another account; andtransferring value from the another account into the account associatedwith the account data.
 11. The method of claim 10, further comprisingtraining the non-sufficient funds classifier based on a training set bydetermining respective weights for the plurality of parameters.
 12. Themethod of claim 10, wherein the plurality of parameters include one ormore of: a past non-sufficient funds event; a balance; and an indicationof decrease in income.
 13. The method of claim 10, wherein thenotification is provided in response to determining, while performingthe evaluation operation, that the forecasted balance is expected tofall below a defined threshold.
 14. The method of claim 13, wherein thedefined threshold is zero.
 15. The method of claim 10, whereinperforming an evaluation operation on the account data includesdetermining one or more projected future transfers, and wherein the oneor more projected future transfers include at least one incomingtransfer and at least one outgoing transfer.
 16. The method of claim 10,wherein the account data passed to through the machine learning binaryclassifier includes a transaction listing.
 17. The method of claim 10,wherein the account data passed through the machine learning binaryclassifier includes biographical data.
 18. The method of claim 10,wherein the evaluation operation performed in response to receiving thebinary output indicating that the account is likely to have thenon-sufficient funds event is not performed when a binary output isreceived indicating that the account is not likely to have thenon-sufficient funds event.
 19. A non-transitory computer-readablestorage medium comprising processor-executable instructions which, whenexecuted, configure a processor to: pass second account data through anon-sufficient funds classifier, the non-sufficient funds classifierbeing a machine learning binary classifier that is configured toclassify the account as either likely to have a non-sufficient fundsevent or unlikely to have the non-sufficient funds event, based on anevaluation of a plurality of parameters associated with the accountdata; receive a binary output from the machine learning binaryclassifier indicating that the account is likely to have thenon-sufficient funds event; in response to receiving the binary outputindicating that the account is likely to have the non-sufficient fundsevent, performing an evaluation operation on the account data; provide,to a client device associated with the account, a notification based onthe evaluation operation, the notification including a selectable optionto transfer value from another account; receive a request to transfervalue from the another account; and transfer value from the anotheraccount into the account associated with the account data.
 20. Thenon-transitory computer-readable storage medium of claim of claim 19,wherein the evaluation operation performed in response to receiving thebinary output indicating that the account is likely to have thenon-sufficient funds event is not performed when a binary output isreceived indicating that the account is not likely to have thenon-sufficient funds event.